home *** CD-ROM | disk | FTP | other *** search
/ Developer CD Series 1997 January: Mac OS SDK / Dev.CD Jan 97 SDK2.toast / Development Kits (Disc 2) / OpenDoc Development Framework / ODF-Interest Archive / June 96 / Design Patterns⁄ODF? < prev    next >
Encoding:
Internet Message Format  |  1996-12-03  |  2.4 KB  |  [TEXT/ttxt]
  1. Subject:     Design Patterns/ODF?
  2. Sent:        6/27/96 5:26 PM
  3. Received:    6/27/96 5:41 PM
  4. From:        William R. Jones, wjones@mindspring.com
  5. Reply-To:    ODF Interest, ODF-Interest@CILabs.ORG
  6. To:          OpenDoc Development Framework Discussion List, ODF-Interest@CILabs.
  7.  
  8. Forgive me for resurrecting an ancient thread, but I only recently caught
  9. this while trolling through my mail archives.
  10.  
  11. This Addison-Wesley book, "Design Patterns", is it about the OOD movement
  12. that has its roots in an architectural theory by Alexander? (Archibald?
  13. Atkinson? Something that starts with an A).
  14.  
  15. Patterns, if I may simplify a lot, hold that just about every programming
  16. problem can be reduced to some easily-recognizable archetypes (i.e. stack,
  17. queue, on up in complexity to MVC, etc.), which then suggest or even dictate
  18. how the OO design should be constructed. 
  19.  
  20. It's a very powerful and elegant idea, rife with nuggets of truth. Bt what
  21. concerns me, and others, is that every single building project that used the
  22. original architectural technique was a dismal failure, patchworks that
  23. didn't combine into a useful whole. 
  24.  
  25. It can be argued, of course, that the field of architecture differs so much
  26. from computing that what didn't work there will work fine here. 
  27.  
  28. It may also be argued, though, that OOD/OOP lends itself to such patchworks,
  29. and further that  component systems like OpenDoc and SOM do so as well. I
  30. think one of the biggest obstacles in selling component-based software is
  31. going to be convincing the market that it is a better approach than the
  32. allegedly organic design of monoliths like Word and Notes.
  33.  
  34. So, if I'm building an application on OpenDoc components, on top of a
  35. patterns-like framework like ODF, writing in C++, which resolves to SOM
  36. binaries, I have, in effect, four layers that add tendencies toward
  37. patchiness, which makes me squeamish that I can make my application organic.
  38.  
  39. In addition, I fret over a maxim that has yet to be proved false, in my
  40. experience-- that mapping an abstraction onto an abstraction onto an
  41. abstraction, etc., contributes to code bloat makes for slower systems. Which
  42. is why I know of no real-world implementation of the OSI 7-layer model.
  43. Exactly the opposite of the hopes I had for components in the first place.
  44.  
  45. This just a concern I've had for a bit, but it bothers me enough to have
  46. considered not using ODF or C++ in my own code.
  47.  
  48. Maybe I just spend too much time in engineering seminars.
  49.  
  50. Bill
  51.